just building ubxtool is probably fine for most folk for sure - definitely on the rPi, which is probably the majority of install cases. And why spin up a huge vm/docker just for one binary, if you don't have to?

Exactly! I also prefer to copy a bare binary to the rPi, but someone may prefer a tiny* docker image (e.g., if they already have some kind of docker-based services on the pi), and the image comes "for free" as a byproduct of the build process.

*) galmon image with all the deps and build tools is 728 MiB, ubxtool image is ~ 18 MiB, ubxtool.nodeps.x86_64 binary is 12 MiB (not stripped).

I've updated the code to produce the binary that works on Raspberry Pi 1 B+ (and Zero) as well. I faced couple of issues while doing that:

• the Ubuntu (and Debian) armhf buildroot was targeting armv7 (per readelf -A ubxtool as well), so first-gen raspberry was unable to run the built binary, but RPi3 worked okay.
• the "latest stable" alpine 3.11 buildroot for armv6 has a combination of g++ and musl-libc that was unable to build usable static binary.
• clang-9 in alpine 3.11 was producing opcodes for 32 (not 16) double-sized FPU registers while doing code for VFPv2. So the binary crashed with SIGILL on RPi1.

clang-8 and recent clang-10 should not be affected.

Maybe I've done something wrong, I have known almost nothing about the difference between CPU/FPU of various Pi boards before yesterday. :-) The binaries produced by the script runs at stations 50, 51 and 52 without noticeable issues. Following links helped me to understand what was going on:

• elinux.org maps hardware revisions at /proc/cpuinfo to Pi model names, so that can be done with nothing but ssh access
• Debian wiki on Raspberry summarizing the binary difference between Debain and Raspbian
• Debian wiki on ARM FPUs
• people writting down the exact model of CPU of various popular ARM boards: 1, 2, 3